Communications devices, such as mobile telephones or personal computers, allow a subscriber to attach to a communication network and communicate with other devices. Furthermore, a growth area is that of machine to machine (M2M) communication, in which communications are sent between different devices without human intervention. Examples of the use of M2M communication include sensor networks (for example, networks for monitoring weather conditions), surveillance equipment (for example alarm systems, video monitoring, and so on), vehicle fleet management, vending machines, monitoring manufacturing and so on.
It is predicted that in the long term future, there will be billions of M2M devices, and the number of M2M devices will far exceed the number of devices used for communication between humans (such as mobile telephones, personal computers and so on).
M2M devices may include actuators in order for the M2M device to receive an instruction and act upon the instruction. There are many uses of M2M devices, and they can potentially consume a lot of network resources.
A typical feature of such devices is that they have limited energy resources, and so are termed “energy constrained”. Energy is consumed when the device is activated and communicates with a network, and takes readings or operates an actuator. It is advantageous to limit the amount of energy used by the device and to minimise any unnecessary use of energy in order to prolong the useful life of the device.
Energy constrained sensor and actuator devices typically register their resources and capabilities thereof to directory services (e.g. the IETF CoRE Resource Directory or RD for short in the rest of the text) for the purposes of reachability, discoverability by applications and inventory maintenance. A Resource Directory (RD) is required because the devices may often be in a sleep mode or in a network where multicast traffic is inefficient. An RD hosts descriptions of resources held on other servers which allows applications to look up available resources. A device may register with one or more RDs. The RD maintains all the metadata that describe the sensor and the produced data.
Devices can also benefit from the existence of a data cache service where they push the current sensor resource representations (e.g. the IETF CoRE Mirror Proxy). A Mirror Proxy (MP) allows applications to obtain the data pushed to the MP without contacting the device. The MP maintains the last known snapshot of the sensor data, e.g. the last vibration measurement for an industrial motor, which is refreshed periodically.
The use of RDs and MPs allows applications to obtain information from the device while eliminating the need for the device to remain in full power mode at all times, which would otherwise deplete the device's energy resources. The RD 2 and the MP 3 also protect the device 1 from Denial of Service (DoS) attacks.
FIG. 1 illustrates an exemplary network in which a device 1 registers with a RD 2 and pushes data to a MP 3. Applications 4, 5, 6 can query the RD 2 and the MP 3 directly without needing to contact the device 1. The dashed lines in FIG. 1 represent resource description related messages (registrations, queries), while the solid lines represent data access related messages. The placement of these functions in the topology of a network can vary. For example the RD 2 may be placed on a sensor gateway (e.g. building GW) or in the cloud. The RD 2 and the MP 3 may be co-located at one node or separately located at different nodes.
A type of network in which a device 1 communicates with RDs 2 and MPs 3 may require the device 1 to send multiple messages to RDs with registration information and sensor data to multiple MPs. This is also the case for devices that may run multiple applications from different stakeholders. While the example of FIG. 1 shows one device 1 registration to one RD 2, and one MP 3, the device may need to register with several RDs and push data to several MPs.
The device 1 (and applications 4, 5, 6) must initially perform discovery to determine the existence of at least one RD 2. The discovery of one or more MPs 3 can be done by the use of the RD 2 itself since, in the IETF architecture, the MP 3 is considered as another resource. Although the RD 2 is also considered in IETF as another resource, there is currently no solution for the device 1 to discover the RD 2.
A further problem arises in the case where the device 1 must communicate with multiple RDs and MPs. A device may be required to register with multiple RDs and push its data to multiple MPs in order to provide load balancing in the network, or for commercial reasons (for example, if multiple network operators are involved). If application developers would like to discover any resource and access any resource representation regardless of the telecom operator they are cooperating with, a network support function must be provided that allows the applications 4, 5, 6 to perform resource discovery and have resource access across different domains.
In the case where there are multiple RDs and MPs, the device 1 must initiate multiple registration requests to multiple RDs and push its data to multiple MPs assuming a full replication policy. Moreover, if the device 1 includes a multi-sensor platform (e.g. it has sensors for different conditions, e.g. light, temperature etc.), the device's 1 resource description includes all of the primitive sensor modalities and the MP 3 would need to maintain all the sensor resources corresponding to the different modalities. For reasons of load balancing on the network, there may be a need for dedicated MPs for specific sensor modalities (e.g. electricity meter readings only and not device management information). Communication with multiple RDs and MPs further drains the energy resources of the device 1.